Hi! Thanks for your PR. Someone else reported the same issue before (#105), but in that case, changing from write_text to write_bytes was the solution 😅 (also see v0.21.2)

My understanding is that write_text normalizes the line endings based on the OS, which may or may not be what you want depending on your Git core.autocrlf and core.eol settings. write_bytes is supposed to preserve whichever line endings the file originally had, so it's not clear to me why they would be changing here.

For what it's worth, I'm on Windows, and I used to see this issue with write_text, but I haven't been seeing it with write_bytes. I'm not sure what environment/config difference might account for that.

Ah, thanks for your reply! I guess the behavior makes sense, actually. Python does this newline normalization, which means it reads both LF and CRLF as LF. Then, it writes LF as CRLF or LF depending on the platform. So when reading and then writing text, LF will be preserved on Linux and CRLF on Windows, but CRLF will be converted to LF on Linux, and LF to CRLF on Windows. This is what was happening in issue #105.

Currently, the usage is asymmetric: read_text and write_bytes are used. This means they are normalized to LF on read and then written as LF no matter the platform. Instead, if we really want to preserve the original newlines, we have two options:

1. Use both read_bytes and write_bytes
2. Use open(..., newline="") for reading and write_text(..., newline="") for writing

I would say using the newline="" argument is the option that conveys intent better, but unfortunately there is no newline argument to read_text. Also, the one for write_text only exists since Python 3.10. So I think the first would be the best option, replacing calls to read_text with read_bytes(...).decode("utf8"). Do you agree? :)

Ah, that's a great point about read_text. I agree that read_bytes would be a good solution :)